차근차근정확하게

Onz 프로젝트 소개 및 기획

Properties1
tags학습, 토이프로젝트, spring-boot, jpa, aws, docker, oauth

9 min read

Onz 프로젝트 소개 및 기획

NOTE

칵테일 바 정보/메뉴 제공 개인 프로젝트 “Onz”의 기획 배경, 기술 스택, 기능 설계, 초기 아이디어 검토 기록.

프로젝트 개요

Onz는 주변 칵테일 바 정보와 칵테일 레시피/맛 정보를 제공하는 개인 사이드 프로젝트다.

  • 큰 주제: 칵테일 가게에 대한 정보를 모아 메뉴를 보여주는 서비스
  • 서브 기능: 유명 칵테일의 제조 방법(레시피)을 간단히 보여주는 “칵테일 백과” 탭

기술 스택

  • Spring Boot, JPA
  • AWS EC2 / RDS (MariaDB)
  • Docker (컨테이너 배포)
  • OAuth2 소셜 로그인 (Google / Naver / Kakao / Apple)

기획 배경

가게 정보 수집 방법 검토

  1. 웹 크롤링
    • 카카오맵 가게 리스트 크롤링 도구 활용 검토 (예: octoparse류 템플릿)
    • HTML 직접 파싱(jsoup 계열 라이브러리) 검토
    • 위치 기반 정보 + 가게 상세 정보를 프론트에 전달하고, 지도 표시는 프론트 책임으로 분리
  2. 공식 API 활용
    • 클라이언트 단에서 지도/장소 데이터를 직접 조회하고, 서버는 부가 데이터(리뷰, 북마크 등)를 처리하는 방향이 더 적합하다고 판단

서비스 특이점

  • 칵테일 바는 바텐더의 스타일과 손님 컨디션에 따라 주조 방식이 유동적 → 단순 정보 제공을 넘어 소통 공간이 필요할 수 있음
  • 확장 가능성으로 메시징, 알림, 예약, 결제 기능을 후보로 검토했으나 커뮤니티 기능은 “리뷰 기능이 이를 대체할 수 있다”고 판단해 범위에서 제외

경쟁 서비스 비교

  • “마실랭” 계열 서비스와 초기 구상이 유사 (데이터는 풍부하지만 추천 기능이 약함)
  • “쉐이커” 계열 서비스는 데이터는 적지만 추천 기능이 강점 → Onz는 두 축(데이터 + 맞춤 추천)을 함께 갖추는 방향으로 설계

소셜 로그인 중복가입 방지 검토

여러 소셜 플랫폼(구글/네이버/카카오)으로 각각 가입한 사용자가 동일 인물인지 식별하는 문제를 검토했다.

전제 조건: 동일 사용자 식별을 위해서는 플랫폼 간 공통되면서도 사용자 개인에 종속적인 데이터가 필요하다 (예: 휴대폰번호, 주민번호).

플랫폼휴대폰번호 확보 가능 여부비고
네이버 / 카카오가능본인 인증된 번호를 등록하므로 신뢰도 높음
구글가능하지만 신뢰도 낮음본인 인증 없이 등록 가능 + 필수값이 아니라 없을 수도 있음

검토한 3가지 방법

  1. 자체 휴대폰 인증: 서비스에서 직접 인증을 받아 플랫폼 간 대조 — 구글 계정은 인증되지 않은 번호라 신뢰도가 떨어지는 한계
  2. 정보 조합 활용: 이름 + 나이 + 이메일 앞자리 조합으로 동일인 추정 — 동명이인·같은 나이·이메일 형식 중복 시 오판 우려
  3. 플랫폼별 독립 관리(채택): 소셜 로그인 계정을 플랫폼별로 완전히 분리 관리 — 보안상 안전하고 민감 개인정보를 수집하지 않아 문제 발생 소지가 가장 적음

최종적으로 방법 3(계정 독립 관리)을 채택했다.

기능 설계

대분류소분류설명
칵테일 정보칵테일 등록SQL 직접 등록 또는 사용자가 이미지 첨부와 함께 직접 등록 가능
칵테일 수정SQL 직접 수정, 등록한 사용자만 수정 가능
칵테일 삭제SQL 직접 삭제, 등록한 사용자만 삭제 가능
칵테일 맛칵테일 맛 등록-
칵테일 맛 맵핑칵테일 정보와 맵핑
칵테일 도수칵테일 도수 등록낮음/중간/높음 3단계
칵테일 도수 맵핑칵테일 정보와 맵핑
칵테일 조회맞춤 정보 조회조건에 맞는 칵테일이 여러 개면 랜덤으로 1개 노출
전체 조회칵테일 전체 목록 조회
필터링 조회맛/도수 기준 필터

칵테일 정보 처리 방식

  • 맞춤 설정 조회 결과가 여러 개일 경우 랜덤으로 하나만 노출
  • 맛과 도수는 enum으로 값을 제한해 데이터 정합성을 보장
  • 사용자가 직접 등록하는 칵테일은 이미지·이름·재료·레시피만 자유 입력으로 열어두고, 도수·맛은 정해진 선택지 중에서 고르게 함

맛 분류 체계

칵테일의 맛을 4개 대분류, 각 대분류를 2~3개 세부 뉘앙스로 나누어 정의했다.

대분류세부 뉘앙스
쌉사름가볍고 향긋 / 진하고 묵직
새콤함톡 쏘는 상큼 / 과일의 자연스러운 상큼
달콤함가볍고 상큼함 / 부드럽고 크리미한 / 진한 캐러멜
강렬함스파이시 자극적 / 묵직하고 깊은

캐싱 처리 검토

칵테일 정보처럼 변동성이 거의 없는 정적 데이터는 매 요청마다 DB를 조회할 필요가 없다고 판단해 인메모리 캐싱을 검토했다.

  • 검토한 캐싱 단위: 객체 단위 캐싱(사용처에서 개별 관리) vs DTO 단위 캐싱
  • 인메모리 캐시 채택 시 고려사항: DB와의 동기화 문제 — 다만 대상 데이터가 변동성 없는 정적 데이터라 이 문제의 영향이 크지 않을 것으로 판단

온보딩(약관 동의) 흐름

최초 소셜 로그인 여부에 따라 아래와 같이 분기한다.

소셜 로그인 시도
   │
   ▼
최초 로그인 여부 체크
   │
   ├─ 첫 로그인 → 약관 동의(연령/서비스/마케팅/광고성) → 회원가입 처리
   │
   └─ 기존 회원 → 바로 로그인 처리 (JWT 토큰 발급)

관련 문서

그래프 뷰

백링크